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Reply to Office Action of January 10, 2006 

REMARKS 

Reconsideration of the application, in light of the amendments and arguments herein is 
respectfully requested. 

I Status of the Claims 

Claims 1, 2, 4, 5, 21, 23-27, 40, 42, 43, 46, and 55 have been amended and the 
amendments do not add new matter. Support for the amendments are in the Specification, page 8, 
lines 3-10. 

Claims 3, 6-13, 16, 18-20, 22, and 49-54 have been previously cancelled. 
Claims 1, 2, 4, 5, 14, 15, 17, and 21, 23-48 and 55-57 are pending and at issue. 

II Rejections under 35 U.S.C, S 102 

Claims 1, 2, 4, 5, 14, 15, 17, 21-48, and 55-57 are rejected under 35 U.S.C. § 102(e) as 
anticipated by U.S. Patent No. 5,959,876 to Ginter et al. ("Ginter"). Applicants respectfully traverse 
the rejection. 

In response to the Examiner's comments, Apphcants amended the claims to positively recite 
the validating elements. Further, the Examiner states that the claims are not consistent with the 
previous arguments. Specifically, the Examiner contends that the validation step is not claimed to 
take place before the transaction between the retailer and the consumer. Applicants respectfully 
disagree. The claims recite the "validation" step and then the step of "providing the electronic 
media content" depends on successful validation. The transaction contemplated between the 
consumer and the retailer is an exchange of funds for the electronic media content, and the 
transaction is not complete until both parties perform the exchange. As claimed, the retailer does 
not perform his portion of the transaction until after successful validation . Thus, the "validation" 
step is performed before the transaction is completed. 
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However, in the interest of forwarding prosecution, the claims have been amended to 
explicitly recite that the validation step is performed prior to the completion of the transaction. For 
example, claims 1, 27, and 40 have been amended to recite that the compensation is not received 
until after successful validation. Thus, neither element of the transaction can be performed prior to 
the validation step. Claims 21, 24, 25, and 55 have been amended to recite that the candidate retail 
offer (transaction) is not fulfilled or completed until after successful validation. Thus, Applicants 
respectfully submit that the present amendments explicitly recite that the validation step occurs prior 
to the completion of the transaction between the retailer and the consumer. 

hi response to the rejection over Ginter, Applicants reiterate their argument submitted in the 
Amendment filed February 15, 2005 (arguments attached hereto as Exhibit A). In summary, 
Applicants continue to submit that Ginter does not teach every aspect of the claimed invention. 
Ginter, as a whole, does not teach the settlement of a contract between two parties in the present by 
looking at an existing contract, between different parties. 

Ginter discloses auditing which occurs after a transaction has taken place. One of ordinary 
skill in the art is aware that an audit caimot be performed before a transaction. Thus, Ginter does 
not teach validation of the offer between the retailer and the consumer before the transaction so as to 
allow the transaction to take place. 

Also, Ginter may arguably suggest one or more ways to create an e-contract, but does not 
show the claimed method and system for validating a later offer, by a different party, against an 
earlier contract. Claim 1 provides for a predetermined contract between a distributor and a retailer 
previously agreed upon. The candidate retail offer is presented to and exercised by the consumer. 
The candidate retail offer is then validated against the previously agreed upon contract between the 
distributor and retailer before the transaction with the consumer is consummated. 

Further, the present invention centers on content and transactions concerning the content 
based on previously negotiated and agreed upon contractual terms. In contrast, Ginter centers on 
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negotiations between parties to form a contract. The claimed method of validating an offer against a 
contract is in contrast to a negotiation of distribution terms among any two or all three of the parties. 

Furthermore, Ginter also does not address the problem that the earlier contract may change 
after it is first formed and before a candidate retail offer is made to a consumer. Ginter falls short of 
the claimed method, which begins where Ginter ends. The claimed invention allows parties outside 
the distributor/retailer relationship to purchase content in accordance with the contract previously 
negotiated and agreed upon between the distributor and the retailer. The electronic contract is not 
accessed until the time of the user's request, so the most current contract is used. 

Applicant submits that Ginter discloses only a "static value chain management system." The 
term is defined in a whitepaper, The Long March to Interoperable Digital Rights Management, page 
6, written by members of InterTrust (attached hereto as Exhibit B). InterTrust is the assignee of 
Ginter. Ginter only discloses packaging the rules, either with or without the content, and sending 
them down the value chain. 

Exhibit B also defines a "dynamic value chain management system" and the differences 
between the two {see, pages 6-7). Applicant's system and claims are a dynamic value chain 
management system, the information is accessed as needed. The offer for the content is validated at 
the time the user wants to exercise the offer, thus when the information is needed. Exhibit B cites, 
in footnote 10, the Content Reference Forum (the "CRF") as the source for the dynamic features. 
The CRF was formed by the assignee of the present invention, Universal Music Group. 

Additionally, Applicant respectfiiUy submits that Ginter does not disclose all of the elements 
of the claims as contended by the Examiner. Ginter contains approximately 500 pages of text and 
illustrations. The core concept of Ginter is a "virtual distribution environment" (VDE) that is a 
secure environment for distributing content and rights ("rights" are also referred to as "rules and 
controls"). Around this VDE concept is a huge list of possible variations in electronic commerce 
that can be implemented in VDE. The VDE concept can be used to design many different types of 
secure electronic commerce systems but the description of individual concepts does not equal every 
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different type of system that can be built on such concepts. The elements need to be taken in 
context and assembled as one of ordinary skill in the art would be taught to do so. 

For example, as a simpHstic estimate, if approximately half of Ginter's illustrations disclose 
a single embodiment, there are approximately 75 different embodiments. Chosen at random, one of 
ordinary skill in the art can create approximately 2.5x 10^^^ different variations of Ginter's elements 
(75 factorial (!)). Claim 1 only has 7 elements, and the probability that one of ordinary skill, 
without any teaching or suggestion, would pick certain elements in Ginter over others, to make the 
presently claimed invention, is astronomically small. 

Secure distribution environments and systems were described and built before Ginter. The 
concepts of protecting content and delivering rights separately from the protected content were also 
described and implemented before Ginter. As a matter of fact, the majority of the components that 
Ginter describes were invented before Ginter. If one gives Ginter's description broad interpretation 
and a "benefit of the doubt" where Ginter does not specifically describe something, practically any 
secure electronic commerce system can be attributed to Ginter. But, since many secure electronic 
commerce systems existed prior to Ginter, such an interpretation leads to wrong conclusions and a 
reading of Ginter that is impermissible. The Federal Circuit has stated that for "a prior art reference 
to anticipate in terms of 35 U.S.C. § 102, every element of the claimed invention must be identically 
shown in a single reference. These elements must be arranged as in the claim under review. " In re 
Bond, 910 F.2d 831, 832 (Fed. Cir. 1990) (internal citations omitted) (emphasis added). 

The Federal Circuit's guidance is especially important when one of ordinary skill reads and 
interprets Ginter. hi reading Ginter, context is important because taking phrases out of Ginter, 
without specific context in which they were used, gives Ginter an overly broad interpretation 
unsupported by the disclosure. Giving Ginter a broad meaning outside the scope of the described 
embodiments is beyond how one of ordinary skill in the art at the time the invention was made 
would interpret the disclosure. Applicant contends that Ginter must be interpreted according to the 
described embodiments because one of ordinary skill in the art would not understand the disclosure 
otherwise. In other words, if Ginter's concepts can be used to create a system X but X is not 
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described in that context, the claimed system including X is not described or inherent in Ginter. 
While Ginter' s language is purposely trying to be as broad as possible, the description only provides 
a teaching for a "linear" system where content and rights "flow" downstream, from the creator 
through the retailer to the consumer. Thus, Ginter is a "static value chain management system" as 
discussed above. 

Ginter teaches protected "containers" traveling throughout his system for protecting content. 
Ginter further discloses that, generally, rights are delivered with the content but can be delivered 
separately. The secure VDE environment allows the rights to be modified (and/or added to) by 
downstream value chain participants, hi contrast, the invention embodied in the claims is designed 
to have a "feedback loop" whereby the most current applicable rules and relationship data are 
applied to the transaction. This is recited in the claims as "applying derivation rules to said relevant 
relationship data to derive terms of the exchange-of-value transaction based on the relationships 
between said value chain participants." 

The structures that embody the concepts are the Reference Services that are designed 
specifically to house the current business rules and apply them on demand. VDE concepts, using 
impermissible hindsight, may be used to design such a system, but Ginter does not specifically 
describe or suggest it. Hindsight, in this manner, is impermissible. The Federal Circuit instructs in 
Interconnect Planning Corp, v. Feil, 174 F.2d 1 132 (Fed. Cir. 1985) that it is an error to reconstruct 
the patentee's claimed invention from the prior art by using the patentee's claim as a 'blueprint.' 
When prior art references require selective combination there must be some reason for the 
combination other than hindsight. Applicant submits that the Examiner is taking out-of-context 
statements and attributing to Ginter meanings that are not specifically taught, suggested or inherent. 
As pointed out above, with such approach, any electronic commerce system may be improperly 
found in Ginter. 

Thus, claims 1, 2, 4, 5, 14, 15, 17, 21-48, and 55-57 are not taught or suggested by 
Ginter. Applicants submit that Ginter does not disclose all the elements of the claims and 
respectfully request the rejection be withdrawn. 
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CONCLUSION 



In view of the above, each of the presently pending claims in this appHcation is believed to 
be in immediate condition for allowance. Accordingly, the Examiner is respectfully requested to 
pass this application to issue. 

The Examiner is respectfully requested to contact the imdersigned at the telephone 
number indicated below once he has reviewed the proposed amendment if the Examiner believes 
any issue can be resolved through either a Supplemental Response or an Examiner's Amendment. 

Dated: April 7, 2006 Respectfully submitted, 



By 

Louis J. DelJuidice 

RegistratioWNo.: 47,522 
DARBY & ofouBY P.C. 
P.O. Box 5257 

New York, New York 10150-5257 
(212) 527-7700 
(212) 527-7701 (Fax) 
Attorneys/Agents For Applicant 
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REMARKS 

Reconsideration of the application, in light of the amendments and arguments herein is 
respectfully requested. 

I Status of the Claims 

Claims 34-36 have been amended and the amendments do not add new matter. 

Claims 49-54 have been cancelled without prejudice or disclaimer of the subject matter 

therein. 

Claims 3, 6-13, 16, 18-20 and 22 have been previously cancelled. 

Claims 1, 2, 4, 5, 14, 15, 17, and 21, 23-48 and 55-57 are pending and at issue. 

II Rejections under 35 U.S.C. $ 102 

Claims 1, 2, 4, 5, 14, 15, 17, 21-48, and 55-57 are rejected under 35 U.S.C. § 102(e) as 
anticipated by U.S. Patent No. 5,959,876 to Ginter et al. ("Ginter"). Applicants respectfully traverse 
the rejection. 

hi response to the Examiner's suggestion that the Apphcants fully consider the reference in 
its entirety, Applicants respectfully submit that Ginter has been reviewed extensively and in its 
entirety. Applicants respectfully respond to the Examiner's comments by reminding the Examiner 
that "for examination under 35 U.S.C. 102, the reference must teach every aspect of the claimed 
invention either explicitly or impliedly." MPEP § 706.02 (IV) (emphasis added). 

Applicants continue to submit that Ginter does not teach every aspect of the claimed 
invention. Ginter, as a whole, does not teach the settlement of a contract between two parties in the 
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present by looking at an existing contract, between different parties. For example, the passage cited 
by the Examiner to refute Applicants' argument that the Ginter is silent on this matter is Ginter, 
colmnn 251, line 60 to column 252, line 64. However, that passage is directed to using metering to 
allow the distributors and financial clearing houses to be audited . Auditing reviews reports after a 
transaction has taken place. One of ordinary skill in the art is aware that an audit cannot be 
performed before a transaction. Thus, Ginter does not teach validation of the offer between the 
retailer and the user before the transaction so as to allow the transaction to take place. Applicants 
admit that there may be agreements between a creator, distributor, and clearinghouse but 
compliance with those agreements is reviewed after a transaction has taken place. There is no 
teaching or motivation in Ginter that electronic versions of the agreements are used to validate 
transaction between the user and retailer. 

Addressmg the Exammer second comment that the claims do not recite the element of the 
previous agreement bemg dynamically updated. Applicants respectfully dh-ect the Examiner to 
claims 29, 30, 33, and 35 that specifically claim that the electronic contract, or portions thereof, are 
dynamically updated. The Examiner rejects claims 29, 30, 33, and 35 by reference to the disclosure 
of Ginter, Figure 2. Applicants respectfiilly submit that Ginter, Figure 2 does not disclose dynamic 
updating of electronic contracts. 

Figure 2 illustrates electronic highway 108 over which the content travels between parties 
and reports and payments network 118. Network 118 passes bills and financial reports and/or 
payments. Neither highway 108 nor network 118 illustrate or suggest dynamic updates of e- 
contracts. See, Ginter, column 53, line 20 to column 54, line 21. Arrows 104, 110, 120, and 122 
show the flow of data between the parties, but in no way presume that the data is accessed and 
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updated dynamically. Specifically, arrows 104, 110 illustrate the passage of "rules and controls" 

but there is no disclosure that rules and controls between the content creator and the distributor are 

accessed and used to validate the transaction between the distributor and the user. On the contrary, 

Ginter describes Figure 2 as follows: 

Arrow 104 shows the content creator 102 sending the "rules and controls" associated 
with the content to a VDE rights distributor 106 ("distributor") over an electronic 
highway 108 (or by some other path such as an optical disk sent by a delivery service 
such as U. S. mail). The content can be distributed over the same or different path 
used to send the "rules and controls." The distributor 106 generates her own "rules 
and controls" that relate to usage of the content. The usage-related "rules and 
controls" may, for example, specify what a user can and can't do with the content and 
how much it costs to use the content. These usage-related "rules and controls" must 
be consistent with the "rules and controls" specified by content creator 102. Arrow 
110 shows the distributor 106 distributing rights to use the content by sending the 
content's "rules and controls" to a content user 1 12 such as a consumer. The content 
user 1 12 uses the content in accordance with the usage-related "rules and controls." 

Thus, Ginter describes that the creator sends mles to the distributor and the distributor sends rules to 

the user. Ginter is silent on using the rules between the creator and the distributor to vahdate the 

offer made by the distributor to the user. 

Ginter may arguably suggest one or more ways to create an e-contract, but does not show 
the claimed method and system for vahdating a later offer, by a different party, against an earlier 
contract. In contrast, claim 1 provides for a predetermined contract between a distributor and a 
retailer previously agreed upon. The candidate retail offer is presented to and exercised by the 
consumer. The candidate retail offer is then validated against the previously agreed upon contract 
between the distributor and retailer. 

Specifically, the claims provide an electronic contract previously negotiated and settled 
between a distributor and a retailer. The contract refers to the terms under which the retailer can 
distribute content. This is the electronic contract claimed in claim 1 and the remainder of the 
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independent claims. A candidate retail offer is presented to a consumer and the candidate retail 
offer is related to the content. The candidate retail offer can be created by the retailer or created by 
others for the retailer to offer to the consumer. The consumer selects a candidate retail offer and 
the offer is validated against the electronic contract. 

The validation of the candidate retail offer involves ''accessing the electronic contract and 
determining if the candidate retail offer is consistent with the electronic contracf\ Thus, the 
electronic contract is formed in advance of receiving a candidate retail offer and the candidate retail 
offer is thereafter validated against the electronic contract when a consumer is ready to make a 
purchase, hi this way, the most up to date electronic contract is used and a consumer's purchases 
are only completed if validated. Ginter does not disclose or suggest previous agreements being 
updated and accessed dynamically for validation, so that an offer to a consumer (a third party) can 
be authorized and processed. 

Further, the present invention centers on content and transactions concerning the content 
based on previously negotiated and agreed upon contractual terms. In contrast, Ginter centers on 
negotiations between parties to form a contract. For example, Ginter may suggest one or more 
ways to create an e-contract, but does not show the claimed method and system for validating a later 
offer, by a different party, against an earlier contract. Significantly, Ginter also does not address the 
problem that the earher contract may change after it is first formed and before a candidate retail 
offer is made to a consumer. 

Thus, the claimed validation step provides that if the terms of the offer do not match the 
electronic contract, the candidate retail offer is not validated. The electronic contract and the 
candidate retail offer do not "haggle" or negotiate to form a new contract, as taught by Ginter. 
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Ginter dedicates over 9 columns to discussing the negotiation of contracts and discloses: 

Negotiation and Electronic Contracts... Electronic agreements, like traditional 
agreements, may be negotiated between their parties... Negotiation is defined in the 
dictionary as "the act of bringing together by mutual agreement." The preferred 
embodiment provides electronic negotiation processes by which one or more rights 
and associated controls can be established through electronic automated negotiation 
of terms. ... A more complex form of a negotiation is analogous to "haggling." In 
this scenario, most of the terms and conditions are fixed, but one or more terms (e.g., 
price or payment terms) are not. For these terms, there are options, limits, and 
elements that may be negotiated over. 

See, Ginter, column 241, line 55 to column 250, line 67. 

Li contrast. Applicants claim that either the candidate retail offer matches the terms of the 

electronic contract or it is not vahdated. Once validated, the content is provided to the consumer, 

the consumer pays, and the compensation is distributed to the parties per the electronic contract. 

Thus, in the claims, there are three parties involved in a transaction, the distributor, the retailer and 

the consumer. The distributor and retailer negotiate and form an electronic contract for the 

distribution of content. The consumer, who is not a party to the electronic contract, is still subject to 

its terms because the terms of the electronic contract govern the validation of the offer the consumer 

is requesting. For example, the Specification discloses that: 

An electronic contract represents an agreement between two or more entities, 
typically the retailer and distributor of some media. ... A "distributor-retailer 
distribution contract" sets forth the terms and conditions under which the retailer 
may distribute media to consumers. ... The e-contracts and business rules related to 
distribution are accessed and applied when the system validates an offer. 

Specification, page 3, lines 5-9 and page 13, lines 20-21. 

The claimed method of validating an offer against a contract is in contrast to a negotiation of 

distribution terms among any two or all three of the parties. Ginter differs and is concerned with 

forming an electronic contract between two parties by negotiating terms between them, using 
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software (i.e. agents), until an agreement is reached or negotiations fail. Ginter discloses the 

negotiation of a contract electronically. Ginter discloses two parties to the contract and each party 

sets out their terms and preferences for the contract as a control set. The two control sets are in the 

nature of bids, and are compared electronically against each other to find mutually acceptable terms. 

Ginter defines the electronic comparison of terms as his "negotiation." The expression of the 

accepted terms becomes a new control set and is incorporated into an electronic contract between 

the parties. See, Ginter, column 241, line 55 to column 254, line 34. 

Claim 1 of Ginter, cited by the Examiner, supports this interpretation: 

[a] method for negotiating electronic contracts, comprising: receiving a first control 
set fi-om a remote site; providing a second control set; performing, within a protected 
processing environment, an electronic negotiation between said first control set and 
said second control set, including providing interaction between said first and second 
control sets; and producing a negotiated control set resulting fi*om said interaction 
between said first and second control sets. 

Ginter's first and second control sets are not electronic contracts. Both control sets are, at best, 

offers to sell or bids for purchase. Ginter states that: 

[o]ne control set may describe a fixed ("higher") price for using the content. Another 
control set may describe a fixed ("lower") price for using the content with additional 
control information and field specifications requiring collection and return the user's 
personal information. ... To perform the negotiation, one party may propose a 
control set containing specific fields, control infi^rmation, and limits as specified by a 
PERC [Permissions Record]; the other party may pick and accept firom the control 
sets proposed, reject them, or propose alternate control sets tiiat might be used. The 
negotiation process may use the permitted, required, and optional designations in the 
PERC to determine an acceptable range of parameters for the final rule set. Once an 
agreement is reached, tiie negotiation process may create a new PERC and/or URT 
[User Rights Table] that describes the result of the negotiation. The resulting PERCs 
and/or URTs maybe "signed" (e.g., using digital signatures) by all of the negotiation 
processes involved in the negotiation to prevent repudiation of the agreement at a 
later date. 
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Ginter, column 243, line 25 to column 244, line 5. Thus, Ginter's control sets are defined, 
exchanged, modified and negotiated until there is an acceptable agreement between the parties. 
There must be an agreement about what the control set includes (the specific fields) as well as the 
content or terms that will constitute a match. Only when all of the terms are accepted is an 
electronic contract formed, which Ginter discloses as a new control set that is "signed" by the 
parties. The definition of the term "negotiation" as defmed by Ginter, "the act of bringing together 
by mutual agreement" (Ginter, column 242, lines 5-6) would lead one of ordinary skill in the art to 
reahze that a contract has not yet been formed, since one does not "bring together" parties after a 
contract is agreed upon. 

Ginter falls short of the claimed method, which begins where Ginter ends. The claimed 
invention allows parties outside the distributor/retailer relationship to purchase content in 
accordance with the contract previously negotiated and agreed upon between the distributor and the 
retailer. The electronic contract is not accessed until the time of the user's request, so the most 
current contract is used. 

Furthermore, even if Ginter suggests to one of ordinary skill in the art that three parties can 
negotiate a contract using Ginter's method (which Apphcants submit that it does not), Ginter still 
falls short of the claimed invention. Using Ginter's method, the distributor, the retailer and the 
consumer would all send control sets to negotiate a single contract, with the consumer's control set 
having input into the relationship between the distributor and the retailer. All the parties would 
negotiate contemporaneously until an agreement is reached. There would be no need for an offer 
validation step because no electi-onic conh-act would be formed prior to the consumer's negotiations. 
Alternately, if the Examiner assumes that the distributor and retailer use Ginter's method for 



one 
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contract and the retailer and the consumer use the method for another, this still falls short of the 
presently claimed invention. Ginter's method only negotiates with the control sets at hand, and 
Ginter does not teach or suggest that control sets should come from a previous contract negotiated 
with a different set of control sets between different parties. 

Ginter does not anticipate all the elements of claims 1, 17, 23-27, 40, 42, 46 and 55 and 
claims 2, 4, 5, 14, 15, 21, 28-39, 41, 43-45, 47-48, and 56-57 depend from the independent claims 
and are allowable at least based on this dependency. Applicants respectftilly request that the present 
rejection be withdrawn. 



In view of the above, each of the presently pending claims in this application is believed 



to be in immediate condition for allowance. Accordingly, the Examiner is respectfully requested to 
pass this application to issue. 



CONCLUSION 



Dated: February 15,2005 



Respectfully submitted, 



Registration No.: 47,522 
DARBY & DARBY P.C. 
P.O. Box 5257 

New York, New York 10150-5257 
(212) 527-7700 
(212) 753-6237 (Fax) 
Agent For Applicants 
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The Long March to Interoperable 
Digital Rights Management 

Rob H. Koenen, Senior Member, IEEE, Jack Lacy, Michael MacKay, 
and Steve Mitchell, Member, IEEE 



Abstract — This paper discusses interoperability of digital 
rights management (DRM) systems. We start by describing a 
basic reference model for DRM, The cause of interoperability is 
served by understanding and circumscribing what DRM is *Mn 
the whole." Then we outline and contrast three different 
approaches to achieving interoperability. One approach relies on 
flexible network services to provide functionality where it is 
needed, perhaps by bridging different systems. We describe an 
experimental service orchestration system (NEMO) that enables 
such an approach. 

Index Terms — Digital Rights Management, Trusted 
Computing, Digital Media Distribution, Standards, Web Services 

I. INTRODUCTION 

DIGITAL Rights Management (DRM) is a collection of 
technologies that enable technically enforced licensing of 
digital information. DRM makes it possible for commercial 
publishers to distribute valuable content electronically, 
without destroying the copyright holder's revenue stream. 
DRM can also be used in other settings to enable safe 
distribution of digital content including, for example, 
document management within and between corporations, 
protected email, medical patient records handling, and 
government service access. 

At a minimum, a well-designed DRM system provides: 
Governance: DRM is different from classical security and 
protection technologies [1]. Conventional media distribution 
systems based on conditional access techniques protect media 
during transmission using a control model based on direct 
cryptographic key exchange. DRM systems, on the other 
hand, implement control, or governance, via the use of 
programming language methods executed in a secure 
environment. 

Secure Association of Usage Rules with Information: 

DRM systems securely associate rules with content. These 
rules determine usage of the content throughout its lifecycle. 
Rules can be attached to content, embedded within content 
(e.g., via watermarking), or rules can be delivered 
independently of content. 

Persistent Protection: DRM systems are designed to 
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protect and govern information on a persistent basis 
throughout the content's commercial lifecycle. Protection is 
frequently provided using cryptographic techniques. 
Encrypted content is protected even as it travels outside of 
protected distribution channels. 

The use of DRM in conmiercial end-consumer media 
distribution is controversial for several reasons. DRM allows 
content providers to create licenses that are different from, and 
more rigidly enforceable than, the de facto generally 
understood licenses that have accompanied traditional media 
(CD's, VHS tapes, and DVD's), Conversely, the nature of 
today's DRM technology makes it difficult to automate 
accurately some existing usage conventions, such as the 
United States' fair use traditions or European privacy 
expectations. 

DRM license enforcement requires security safeguards on 
home equipment to protect the interests of content vendors. 
Although it is common for basic utility vendors to install 
security systems around home metering systems (e.g., cable 
television, water, electricity and natural gas), some consumers 
are wary of DRM systems operating on their family PC, which 
is used for many personal tasks besides presenting media. 

Traditional media distribution (before the mid-1990s) has 
been tied to physical media, such as music CD's and video 
tapes. Making and distributing high-quality copies of music 
and video was difficult for the average consumer. Successful 
business models have been well established around the 
processes of manufacturing, distributing, merchandising, and 
charging consumers for individual copies of a work. Early 
electronic distribution systems have likewise been built 
around the notion of digital copies of works ("copy control 
systems"), but this paradigm is becoming less relevant as it 
becomes easier for consumers to manage content as disk files 
on their home network, in their cars, at work, and in school. 

It is easy today to find consumers who would think it 
appropriate to pay full price for a second factory pressed copy 
of a favorite music CD, but who have few misgivings about 
downloading free (unauthorized) digital compressed copies of 
music for which they (or someone in their family) already 
own a commercial CD. Consequently, consumers are 
developing their own ideas of what the right business models 
should be for commercial music licensing. Conmiercial 
publishers are scrambling to work through the business and 
technical hurdles to deploying business models that protect 
their interests and are acceptable to consumers, device 
manufacturers, and service providers. 
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The result is the emergence of DRM-enabled digital music 
services, such as Roxio's Napster service (originally known as 
pressplay), Apple's iTunes Music Store, Musicmatch 
Downloads, and others. Apple's music service has so far been 
the most popular with consumers, but we have not yet heard 
the last word in legal on-line music distribution [2], [3], [4]. 
BuyMusic, Musicmatch, MusicNow, Napster, and numerous 
others use Microsoft's Windows Media Audio format, which 
bundles DRM capability with an audio codec and a file 
format. Apple's iTunes uses an open standard audio codec 
(MPEG Advanced Audio Coding, or AAC) and a proprietary 
DRM system. The Microsoft and Apple formats are not 
compatible. Microsoft's format is supported on the largest 
variety of portable music players, while Apple's format is 
currently supported on only one - its own iPod. (Reportedly 
this is the current top-selling music player [3]). At the time of 
writing, no portable music player supports both formats. 

This paper focuses on the issue of DRM interoperability. 
There are several reasons why DRM interoperability is 
desirable. The content industry desperately needs to deploy 
legitimate content services that compete favorably (based on 
features, not on price) with unauthorized free services. A 
simple and seamless user experience must be part of that goal, 
and DRM interoperability is necessary to achieve it. 

Content providers and e-commerce service providers would 
like to see a healthy business climate from which they can 
multi-source essential technologies like DRM, especially 
when these technologies must adapt rapidly to evolving 
industry needs and consumer expectations. The DRM market 
is strongly influenced by network effects: a DRM technology 
becomes more valuable as it becomes more widely adopted. 
Thus there are strong forces pushing DRM technology 
providers toward interoperability, even as vendors attempt to 
differentiate their products based upon features. 

While many people have articulated a goal for media 
distribution where any content is available to anyone, anytime, 
anywhere on any useful device using viable business models, 
significant barriers exist to the goal of an interoperable and 
secure world of media related services: 

• Overiapping de facto and formal standards 

• Implementation technologies are not interoperable 

• Consumer devices cannot locate and connect to needed 
services 

• Web services standards do not bridge services spanning 
web distribution and personal area network protocols 

• Impedance mismatches between different trust and 
protection models 

• No unified notion of content governance in current 
peer-to-peer distribution models 

We outline some of the possible approaches to achieving 
interoperability, and discuss related issues. We start in the 
next section by describing a basic reference model for DRM. 
The cause of interoperability is served by understanding and 
circumscribing what DRM is "in the whole." We then outline 



and contrast three different approaches to achieving 
interoperability. One approach relies on flexible network 
services to provide functionality where it is needed. Finally, 
we describe an experimental service orchestration system 
(NEMO) that enables such an approach. 

11. Towards a DRM Basic Reference Model 

Commercial practice across a variety of DRM systems has 
matured to a point where robust technical patterns can be 
identified as a basis for establishing a DRM Basic Reference 
Model'. In this section, we consider the architecture of current 
DRM systems in order to identify conunon technical elements 
and the requirements they try to address. Proceeding from this 
analysis, we then outline a reference model that may serve as 
a basis for coordinating evolution and interoperability of next- 
generation DRM systems. Establishing a general vocabulary 
and a set of reference concepts is the first step in building a 
framework for interoperability of heterogeneous systems, 

A . Current DRM A rchitectures and Industry Practice 
Fig, 1 illustrates an abstract system architecture based on 
DRM application and service elements representative of a 
variety of contemporary commercial DRM systems. Key 
concepts in this diagram are as follows: 

• Content and associated usage rights enter the system 
through a packaging process, typically under the authority 
of the Content Licensor. 

• Packaging services produce protected content and either 
full licenses, or rules and metadata as input to a Licensing 
and Reference Service. Licenses can usually be 
personalized based on the particular parameters of the 
license-requesting party [5], 

• Consumers use a local Consuming Application to transact 
with the licensing and reference services for licenses, and 
interact with streaming or download services for 
acquisition of the protected content. Often, the licensing 
service provides the reference to the correct content and 
associated distribution source. 

• The consumer may be licensed to transfer protected 
content to another peer system {e.g. other "full-featured 
hosts"), or to a portable device with DRM capabilities. 
Portable or "tethered" devices interact with the DRM 
system by proxy via a more capable upstream system {e.g. 
the "full-featured host"). The host may for example create 
a restricted form of the original license better suited to the 
capabilities the device, or may buffer or cache certain 
usage information on behalf of the less capable device. 

Each of the elements in fig. 1 may consist of multiple 
systems in a real-world implementation. For example, 
licensing services may embody an entire distribution value 
chain consisting of retail, subscription or download services. 

Each element may be hosted by different business entities, 

' The CEN/ISSS Digital Rights Management Final Report [16] provides an 
overview of evolving DRM technical architectures with the goal of 
"identifying the current status of DRM usage and possible means to ensure 
effective implementation of DRM in the marketplace." 
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acting in cooperation with other parties* systems based on 
contractual business relationships. Current deployment 
scenarios for DRM systems involve mutually well-known 
business partners, carefully architected technical 
responsibilities and negotiated business relationships. 
However, increased business automation and more dynamic 
business relationships create the need for flexible provisioning 
and management of DRM infrastructure. 

DRM applications and services (consumption, packaging, 
license services, provisioning services, etc.) are all built on 
elements of the trusted computing framework, which includes 
secure software distribution and execution environments, 
trusted identity management, secure policy and rule 
processing and enforcement, supporting cryptographic 
functions and key management, and tamper resistance. 
Provisioning services support adding new participants and 
services, and supplying DRM systems with supporting 
software, certificates, etc. 

The ability to programmatically configure and manage 
trusted and secure relationships between the participants and 
the underlying DRM technology is paramount [6], All of the 
parties in the value chain must trust that distributed content or 
information and its source are authentic, is accessible only by 
intended or contracted receivers and is used by those receivers 
consistently with the contracted rights. Devices and services 
must be qualified as trustworthy and then maintained as such. 



B. Value Chains and DRM Systems 

Understanding roles in the commerce value chain and how 
these interact with DRM services is essential. 

A detailed model of roles involved in electronic copyright 
management systems was developed by the European 
Commission-funded Imprimatur project. Completed in 1998, 
the goal of Imprimatur was to "understand and analyze the 
context in which Electronic Copyright Management Systems 
are to be developed," and which "reflect[s] current business 
practices for trading and licensing multimedia documents [by 
identifying] relevant roles, their relationships and 
corresponding transactions" [5]. Roles and responsibilities 
addressed by the Imprimatur model include: 

• The Creator - the party responsible for delivering their 
creation to the Creation Provider. 

• Creators may assign exploitation rights to a Rights Holder 
{e.g. a collection or licensing agency). 

• The relationship between Creators and Rights Holders 
and associated contracts are maintained in an IPR 
Database. 

• The Media Distributor is expected to pass appropriate 
royalties to the Rights Holder according to the current 
payment details stored in the IPR Database. 

• The Purchaser (consumer) may use the creation, and if 
they generate a new composite document based on it then 
they also become a Creator. In order for the Purchaser to 
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perform functions associated with the Creator role, they 
must have obtained the required permission from the 
corresponding Rights Holder of the original creation. 
Rights Holders of original creations automatically have 
rights on composite creations - the flow of royalties is 
determined according to the IPR Database. 

Few DRM systems take all of these types of roles, 
relationships, and activities directly into account as part of 
their intrinsic design, leaving contract management, auditing 
and accounting issues to a diverse array of largely 
unintegrated back office systems. With increased end-to-end 
systems automation and sophisticated digital content 
manipulation and aggregation services, models like 
Imprimatur will likely receive increased atttention in new 
architectures. Possibly the most thorough attempt to date in a 
single DRM system was undertaken by InterTrust in its 
Commerce system [7). 
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Fig. 1 - DRM Basic Reference Model 

C. DRM Systems Functionality 

The proposed basic DRM reference model is illustrated in 
fig. 2. We now frame the functional characteristics of the five 
main domains of our proposed basic reference model. 

}) Packaging, Rules Generation and Modification 
The point of entry to the DRM-managed content and 
governance lifecycle includes technologies supporting content 
packaging, specification of rights and associated data, and 
generation and modification of digital items. 

a) Content Packaging 

Content packaging is the process of preparing content for 
DRM protection - placing content into a secure container, 
usually by encrypting it, associating the necessary identifiers 
and metadata, and logging and cataloging the content, its 
identifiers and metadata, and its cryptographic material. 
Consumers and associated consumption processes may also be 
enabled to package their own content^ 

^ The term "consumer" typically refers to retail end-users but may also 
apply to other value chain participants - regardless, consumers are participants 
of the managed value chain and may participate in a broader class of functions 
than strictly consumption and rendering. 



Content packaging can be closely associated with rules and 
license generation, or may be completely independent from it. 
Content identifiers couple the protected content with rules and 
content protection keys. Therefore, rules, packaged content, 
and content keys may be generated together or separately, at 
the same time or at different times. They may be delivered 
together, through the same channels, or separately, at different 
times, through different channels. In a production 
environment content may be packaged initially without rules. 
Alternatively, content may be packaged on-demand and 
immediately associated with rules. 

The content may contain directions as to where licenses or 
offers associated with the content can be acquired, or other 
offer metadata that can be used to automate downstream 
distribution processes. 

Content protection is typically accomplished using 
cryptographic processing, where content protection keys are 
made available to one value chain participant or consumer, 
and are not exposed in the clear to other value chain 
participants or consumers. Key management procedures can 
bind or associate a content package to any security principal, 
including individual consumers, devices, certain types of 
secure media, or content-sharing networks (e.g., a network of 
home media devices). Associating content with a consumer 
allows the protected content and license to be transported to 
other systems on which the consumer is also authorized. 

b) Rules Generation and Modification 

Any authorized member of the value chain from packager 
to consumer may create rules to be associated with a content 
package. Rules may be used to govern consumer access to 
content as well as to govern the actions of other value chain 
members on the content or information associated with the 
content. For example, usage rules may require authentication 
on access or usage, or require license updates to be obtained 
before operating on the content^. 

Rules may specify consequences such as generation of audit 
records based on content usage actions or attempts at usage, 
such that the audit records are securely delivered to a 
designated authority prior to execution of the action governed 
by the rule. 

Rules are often associated with the whole piece of content, 
but may also be managed at the granularity of a content sub- 
element (e.g. stream, component, etc.). Rules can also be 
associated with a class of content (e.g., all content belonging 
to a particular owner, all audio content, all low-bitrate content, 
etc.) rather than a specific content instance. 

Rules can be delivered as separate files (e.g., a license), or 
combined with the protected content (integrated with the 
content data format itselO, or both. Alternatively, the rules can 
be provided as input to value chain management and licensing 
services, or applied in conjunction with processes for 
resolving references to the content. 

' For example, expired rights might require license updates to enable access 
or usage. 



;//ypackaqirig^i 
'arvdiMiodificatlbn: 




6 



Rules, terms and conditions, and consequences can be 
represented in a variety of different ways. For example, one 
approach is to use a standardized rights expression language 
such as the MPEG-21 Rights Expression Language (REL, [8]) 
or the Open Digital Rights Language (ODRL, [9]). 
Alternatively, rules may also be encoded in formatted text 
(such as XML or named key-value pairs), or possibly via 
compiled or interpretive code as part of an application. 

In some systems, it is possible to modify or extend rules 
after their initial creation. For example, value chain 
management and licensing services may support the ability to 
select and apply rules that have been updated to reflect up-to- 
the-minute changes in business offers, regardless of when the 
content was packaged and placed into the system. 

In the final stage of rules generation, rules are embedded 
into data structures that can be linked to the content. There are 
a variety of mechanisms available for packaging rules. For 
example, sets of rules may be organized into "offers" that 
describe the content and the associated license for presentation 
to a consumer or other value chain member. Offers may be 
delivered to a content distributor, who may choose to present 
some or all of the offers to other participants further down the 
value chain. Associated collateral information and 
promotional content can be included in a separate package for 
use in retail promotion and downstream distribution. 

2) Value Chain Management and License Services 

A common characteristic of systems that support non-trivial 
operational models (such as subscriptions, superdistribution, 
push-distribution, etc.) is the ability to produce, modify, 
assemble and aggregate rules, and negotiate conflicts 
involving rules from one or more sources.. 

Consumer licenses are sometimes the result of a 
collaboration of multiple value chain participants. Authorized 
value chain members may insert new rules into the licensing 
structures, using processes that are themselves governed. The 
rights of various services to interact with the content's 
distribution process may be encoded in nales delivered directly 
to the service or that are referenced using the same identifiers 
or references that are associated with the content. 

Value chain management services may include post- 
transaction processing (e.g., allocation of the value exchanged 
such as financial payment, usage data, etc.) per contractual 
obligations [5], Such post-transaction processing rules can be 
included in the license associated with the content (whether 
packaged together with the license or separately), or created as 
an electronic contract covering specific offers or content and 
delivered separately. 

Historically, the terms by which value chain participants are 
allowed to interact with the content and rights to its use are 
expressed via contractual relationships between creators (or 
creation providers) and other value chain participants. We 
anticipate that contractual relationships may be automated 
using similar mechanisms (e.g. electronic contracts) as those 
used to control access to content by consumer applications. 
Contracts may be encoded using a Contract Expression 



Language [10], similar to rights expression languages used for 
encoding content usage rights. Electronic contracts are then 
delivered to participating entities and used by trusted 
applications to manage content distribution rights. The ways 
in which these terms are delivered and managed are discussed 
in greater detail in the next section. 

Frequently, rights and contractual obligations associated 
with a piece of content already exist as a result of prior 
interactions with the content (e.g. as part of prior distribution 
arrangements). Rights discovery refers to a set of functions 
provided either by technically automated or other means, such 
as conventional business processes, for referencing these 
existing rights and obligations. 

a) Value Chain Management 

Value chain management refers to those system facilities 
that track, serve and govern value chain participants. Value 
chain participants have interests in the distribution of products 
and provide decision-making, reporting, and other processing 
services affecting the digital content under their control. Just 
as rules govern the use of protected content, rules and policy 
govern the ways in which value chain participants interact 
with one another and with their associated content. 

Static value chain management refers to approaches 
where offer and consumption rules are computed at content 
packaging time. An expression of rules can be distributed with 
content packages for examination or modification by other 
participants in the value chain. 

In the static model, content packages are created for a 
particular set of distribution participants. The value chain 
management process is parameterized at packaging time with 
information about the known and identified participants, and 
the packager output conveys the necessary information in 
advance of actual participation. Once packaged, modification 
to the value chain information is governed by the associated 
rule set. The upshot of this early-binding approach is that 
unanticipated business model changes might necessitate 
content and/or rules repackaging from an original source. 

The dynamic value chain management model is late- 
binding. In the dynamic model, rules governing the use of 
value chain information are accessed on demand through 
network services, rather than being carried as they were 
encoded at packaging in an early-bound and immutable 
configuration. Rather than copying packaged files to each 
value chain participant, content may be distributed by 
reference [10]. The rights to the content are distributed based 
on these references and the references may be incorporated in 
or used by other structures, such as licenses. Reference 
Services fulfill requests for content consumption by 
consulting their current rule sets [10]. 

Dynamic value chain management allows for modification 
of the value chain information as references to the content 
move through the distribution channel. The dynamic model 
allows content to be packaged without advance knowledge of 
distribution configurations. Distribution configurations can 
change in response to new contracts, law, or business models. 
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In addition to enabling greater adaptability and responsiveness 
to changes in the business environment, dynamic value chain 
management may provide better ways to accommodate 
complex rights management issues, such as fair use rights. 

b) Licensing Processes 

License services manage and distribute content licenses. DRM 
functions associated with license services commonly include: 

• Management of data structures carrying rules {e.g. 
licenses or offers) and cryptographic information {e.g. 
content protection keys). 

• Discovery, delivery, authentication, and management of 
offers 

• License request processing, license generation, license 
association (binding) and delivery of resulting licenses to 
requesting entities (devices, services, applications or 
security principals associated with authenticated user 
identities) consistent with the requirements of the rights 
holders and governing contracts. 

• Validation of trusted status of entities requesting services 
of the system {e.g. authentication of value chain 
participants and the business relationships between them). 

• Validation of transactions from peer value chain systems 
authorizing generation and association of licenses on 
behalf of a third party, 

• Processing and validation of any rules required for 
delivery of the license, such as enforcement of geographic 
restrictions; enforcement of time restricted offers; and 
validation of credentials from the requesting party. 

• Management and enforcement of subscription data. 

• Event reporting for payment functions (or any other 
exchange of value). 

• Event reporting for usage tracking and overall system 
assurance. 

3) Consumption Services 

Consumption services are functions through which 
consumers interact with DRM content according to some 
governed action {e.g. playback rendering, editing, printing, 
annotation, aggregation, etc.). Consumption services are 
typically associated with consumer client systems, but may 
also be associated with any value chain participant that 
accesses or processes protected content, metadata, or rules. 
Systems incorporating DRM consumption services can take a 
variety of forms including: 

• Application software incorporating DRM functions for 
protected media services running on a general purpose 
OS using PC hardware. 

• Consumer electronics devices such as set-top boxes, 
multi-media appliances or game consoles, etc. 

• Wireless or personal digital appliances, including those 
capable of participating in online transactions with value 
chain management and license services, and supporting 
operational and trust management services. 

Supporting elements of distributed DRM systems, such as 



value chain management services and license services, must 
be able to establish and maintain trust with systems that host 
consumption services. Trusted consumption hosts must protect 
their operation against circumvention of local DRM 
processing functions, must enforce rules governing access to 
packaged data, and must render and otherwise use protected 
content. Systems that consume protected content typically 
employ a variety of security mechanisms and may interact 
with local or distributed security services. 

Consuming systems request and acquire protected content 
through transactions with licensing and potentially other 
services. These transactions may include information about 
the requesting system environment and user context - 
including possibly personalization data, locale, system 
capabilities, security level or evidence of current certification, 
and information about the content. Due to the potentially 
sensitive nature of some of this information, privacy 
protection is a paramount concern in these functions [11]. 

Although many systems associate protected content, using 
cryptographic techniques, to the identity of the requesting 
system {e.g. using a fingerprint based on characteristic 
attributes of the specific system, or an indelible identifier or 
key), it is also possible (and increasingly desirable) to license 
the protected content to an identity associated with an 
authenticated security principal, {e.g. the user or a role 
associated with the user). Establishing this type of association 
allows the protected content and license to be transported to 
other systems on which the user is also authorized. 

Once the license is received, the consuming system is able 
to manipulate the content according to the specified rules.. 
Rules may express, for example, limitations on the number of 
plays, time-based usage or expiration, requirements for 
enrollment in a subscription service, budget transactions with 
a local stored-value database, authorization from a content 
management system within a business or between business 
partners, etc. 

The consuming system's DRM components are responsible 
for enforcing the rules and maintaining any state associated 
with them. State information must be protected in order to 
assure integrity against circumvention for purposes such as 
unauthorized replay or redistribution. 

If the rules specify consequences, the consuming system's 
DRM components are responsible for any required local or 
distributed transactions such as usage auditing, event 
reporting'* or metered payment. Unsuccessful event reporting 
or auditing may result in prohibitions against further access 
until such records can be successfully processed. 

Rules may also specify whether the consuming system has 
the right to copy content to another peer or portable device. In 
this case, the system's DRM components must support device 
interfaces and non-volatile state (such as copy and check-in / 
check-out counts) used to maintain compliance with the rules, 
A device or application to which the content is being 

^Event reporting includes activities such as successful download 
notification. 
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transferred must be able to enforce the applicable content 
usage rules to a required level of conformance. 

a) Consumption and Portable Devices 

In many ways, portable devices are just another class of 
consuming system. Examples of portable devices include 
personal digital music players and various types of imaging, 
games, or electronic book devices. The primary characteristic 
of a portable device is that it is usually managed by a more 
capable system, what we might call a "full-featured host," that 
is capable of direct transactions with distributed value chain 
management and license services. Portable devices typically 
rely on a secure communications channel managed by the host 
system for functions such as copying and (re-)associating 
protected content to the portable device (or a removable 
secure memory) for offline usage and rendering. 

Portable devices typically incorporate many of the 
following functions: 

• The device and/or its portable media may be registered by 
its unique identity with the host system or consumer 
electronics appliance, personal area network, license 
service, or a personalization service. 

• They are certified as compliant with applicable security 
and/or DRM specifications. This is typically represented 
by a certificate associated with the device. 

• A device may register with a host at the time of content 
transfer, by presenting credentials or a unique identity, 
allowing content to be secured to the device. 

• The device may be re-registered to a new network, 
service, etc. in which case it is unregistered from the 
previous attachments. (Content may be keyed to the 
original network and would cease to be renderable.) 

• The device may be disabled, or denied service 
("revoked"), based on its status as a trusted element of the 
comprehensive DRM system. Revocation may involve the 
invalidation of the certificates mentioned above, or 
invalidation of the software component used to transfer 
content in the host device. 

• The host system may require information about the 
portable device including its unique identity, the unique 
identity of any removable secure memory or media 
associated with it, and other functional and/or security- 
related capabilities of the device (including certificates). 

• If authorized, the host system may support format 
translation to a different protected representation that can 
be consumed by the portable device. 

• The host system may support (re-)associating rules with 
the portable device or its removable storage. 

• The host system may support (re-)packaging, re- 
encryption, and securely associating rules to a 
representation supported by the portable device. 

Host system support for a given type of portable device 
typically depends on the security level of the device and its 
DRM capabilities. Usually, rules associated with protected 



content will determine whether the host can undertake 
transactions with a portable device, and. hence the portable 
device may be required to include functionality such as: 

• A secure clock or time source 

• Dynamic device binding to a personal area network or 
home gateway 

• Secure counters for counted plays and subscriptions 

• Device or removable storage hardware unique IDs for 
secure association of rules, content encryption keys, and 
associated protected content 

4) Trust Management Services 

Trust management services are primarily responsible for 
functions supporting provisioning, certification, secure 
operation and renewability of elements in the distributed 
DRM system [12]. Trust management services are relied upon 
by features in virtually all components of the DRM system 
and typically entail functions including: 

• Support for different trust management topologies (e.g. 
peer-to-peer, web of trust, hierarchical trust models) 

• Certification of software and/or hardware 

• Registration of software and/or hardware 

• Registration of business relationships 

• Support for personalization functions provided by the 
security and protected platform services 

• Security lifecycle maintenance including renewability and 
revocation as required for maintenance of distributed trust 
and authorized participation across all system elements 
This applies to software and hardware components of all 
value chain participants and their relationships 

• User certification and credential management services, 

• Centralized audit and event logging services. 

Trust management subsystems use authorization techniques 
to regulate activities with risk potential within and between 
DRM system components. A regulated activity is approved or 
denied according to a predefined trust policy, and according to 
credentials and other evidence surrounding the activity. Trust 
policy can be as simple as a list of trusted activity partners, or 
it can be a complex decision procedure based upon activity 
parameters, such as the value being transacted, or the kind of 
security safeguards in place. 

Trust management topologies arise from the ability of 
relying parties to accept third party recommendations or 
certifications of the relied-upon party. In social contexts trust 
is rarely transitive. (A*s trust of B and B's trust of C does not 
necessarily imply A's trust of C.) Nonetheless, the most useful 
automated trust negotiation systems implement some form of 
(possibly limited) transitive trust model. 

Trust management enables risk management by 
implementing trust policy. Although trust management 
systems may make use of authorization technologies to 
regulate activities with potential risk, trust management 
should not be confused with enforcement of content usage 
rules. Content usage rules implement business models, while 



9 



trust policy implements risk management. Different people 
with different expertise and concerns will author trust policy 
and content usage rules. Trust policy and content usage rules 
have different life cycles, and are distributed and managed 
differently. Trust policy and content usage rules are 
conditioned on different criteria, and have different 
vocabularies. While content access is an activity with risk 
potential, trust policy will apply to other activities as well. 
Despite these differences, content usage rules and trust policy 
may overlap, in vocabulary and in effect. 

5) Security and Protected Platform Services 
A trusted environment for persistent governance of rules 
and content is built on a foundation of security ftinctions. The 
required security functions may leverage trusted hardware if it 
is available {e.g. smart cards, hardware cryptographic 
processors, or evolving standards for trusted hardware in 
general purpose PC and PDA platforms [13]). Security and 
protected platform services and technologies include: 

• Software tamper resistance, whereby host and device 
software and/or firmware is designed to provide 
protection of content buffers, persistent state, key stores; 
the program code may itself be obfuscated to reduce 
potential for reverse engineering; and techniques may be 
employed that detect and disable attacks against the 
software itself [14][1 5]. 

• ' Execution environment security, whereby host and device 

software and/or firmware can be validated with various 
integrity checks to ensure that it is legitimate and has not 
been modified. Some hosts may provide isolated 
processing compartments that protect sensitive processes 
from other processes running on the same platform. 

• Software personalization and individualization services 
that support creation or upgrade of DRM components, 
licenses and information such as certificates required for 
operation of the host or device system. 

• Authentication of the user or other elements to the 
application or local operating system, or with associated 
distributed value chain management and license services. 

Authorization to perform rules processing and actions on 
governed content typically requires that the system performing 
the functions prove the integrity of its security mechanisms to 
other services and applications with which it interacts. (This 
would be enforced by the trust policies of those services.) 
Proving integrity usually involves proving compliance with 
various published security certification criteria developed by 
the relevant stakeholders. Evidence of compliance with the 
applicable criteria is strongly associated with the client or 
device, typically through certificates that are cryptographically 
bound to the system, and integrity protected and digitally 
signed by the certifying party. These compliance certificates 
are then used both by the DRM software as part of its runtime 
validation as well as in various protocols involved in the 
acquisition of protected content, rules and licenses. 



D. DRM Interoperability and the Reference Model 
The DRM reference model described here should be useful 
for building an interoperability framework capable of 
accommodating a heterogeneous universe of DRM systems. 
The breadth of topics involved in standardizing DRM 
interoperability can be seen to be both systemic and cross- 
cutting. The functionality is cross-cutting in the sense that it 
intersects technical concerns spanning application integration, 
component software and mobile code, operating systems, 
distributed services, devices, content management and 
security services. The ftmctionality is systemic from the 
standpoint that it must support operational and business 
concerns spanning diverse value chain relationships [5], 
establishment and management of trust relationships between 
distributed participants, and governance of valuable digital 
goods throughout their lifecycle. 

If the basic domain modeling underlying the shape of the 
DRM RM is robust (we believe it is from our work with it 
over the last year), it will support additional detail design 
work in each given domain, including the basis for mapping 
and reusing applicable standards that may already exist in 
those domains. In this capacity, we believe the DRM RM can 
provide particular value as a tool for better coordinating 
interoperability across a variety of different standardization 
projects (e.g. MPEG-21, OMA, OASIS, W3C, IETF, DVB, 
CR Forum, DOI, etc.). Indeed, we anticipate that other 
"planes" can (and may need to) be defined and mapped onto 
the current two-dimensional modeling. One category of work 
that may benefit from modeling as a separate but coordinated 
peer level plane is the design of ontologies^ for DRM actions, 
consequences and policies, since such topics tend to defy 
confinement to a single layer and may interact with multiple 
domains. 

Fig. 3 illustrates how ftmctionality described in section 2.3 
can be mapped onto the proposed basic reference model. 

Summarizing this section, we have outlined the structure of 
a Basic Reference Model for DRM that embodies dominant 
architectural patterns derived from observation of practice in a 
variety of current systems. DRM systems are evolving in a 
rapidly changing technical environment and thus exhibit a 
significant range of diversity in the design of interfaces and 
protocols, formats, trust and security mechanisms, protection 
mechanisms, governance semantics, and supporting 
functionality. Reference models assist in the formulation of 
common design vocabularies and concepts, which can become 
a further basis for motivating improved interoperability and 
usability. While the current model as presented is only a 
starting point, our experience is that it is an effective tool for 
factoring and organizing technical issues in DRM 
architectures. 



* The MPEG-21 Rights Data Dictionary (RDD - ISO21000 part 1) is an 
example of one such standardized ontology 



10 



• Rights Specification 
- Ruies Packaging 
• Contents Packaging 
- Content Protection 

• Key Management 



- Content Distribution 
• Secure Online License Distribution 
- Rules and Governance Policies Distribution 
• Value Chain Management 




Device Registration 
• Acquire Content and Rights 
- License Processing 
Copying or Moving Content 



- Establishment of Value Chain 
Trust Relationships 



- Protection of Cryptographic 
Secrets 

- Protection of 
DRM Content Processing 

-Protection of Statefut 
Information 



Fig. 2 



• Secure Channels • Trusted Hardware and 

Software (Personalization) 

- Example Functionality Mapping Onto DRM Basic Reference Model 



• Tamper Resistance for 
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III. Interoperability and Directions in Next 
Generation DRM Systems 

This section focuses on interoperability in DRM systems, 
and especially the role of interoperability standards. We ask 
the reader to keep the DRM reference model in mind, as 
technical analysis of interoperability strategies and the 
discontinuities underlying systems* non-interoperability also 
tend to highlight the most important interfaces, services and 
subsystems, and formats and processing points to be 
addressed in ongoing development of the model, 

A. Approaches to Interoperability in DRM Systems 
End-to-end format, services, and device interoperability are 
desirable goals, both for end-users and others involved in the 
digital content lifecycle. Normative specifications for end-to- 
end interoperability are the province of various standards 
bodies - many such efforts are in progress at this time [I]. 
Due to the variety of standards used for different modes of 
distribution, and the diversity of proprietary technologies in 
the absence of any authoritative standard, full interoperability 
is unlikely any time soon through standards-setting activities 
alone. Even where degrees of end-to-end interoperability are 
possible within a particular industry segment, consumer 
demand and new business opportunities frequently introduce a 
requirement for interaction with systems built on different 
agreements and standards. 

Full interoperability can be addressed in several different 
ways, which we explore in the following sections. 

I) Full Format In teroperability 

Full format interoperability expects that the interchange 
representation of the digital content can be consistently 
processed based on agreement between all participants in the 
value chain. The audio CD and the DVD are good examples. 
All participants (creators, distributors, manufacturers, etc.) use 



the same data representation, encoding, protection scheme, 
trust management, key management, etc. Usually there is 
some renewability infrastructure in place to cope with security 
breaches, but in severe cases, the associated standard may 
need to be updated. Full format interoperability usually entails 
robustness criteria and a certification regime to establish 
trustworthiness and security of conformant implementations. 

Pros: Makes it very easy to produce, distribute, and use 
digital content. Also makes it easy for diverse participants to 
economically build mass market applications and devices. 
Promotes efficiency by discouraging redundancy. 

Cons: The approach is rigid. Developing industry standards 
is a long process, to be undertaken when industry 
requirements are understood. Adoption requires a critical mass 
in industry which can take years to establish.. The 
mechanisms specified in a standard may not be the optimal 
choice in any particular market niche. Also, the approach can 
be vulnerable: an attack on one system can compromise all 
simultaneously, perhaps by simply distributing "cracks" on 
the Internet. Some parts of most DRM security systems {e.g., 
obfiiscation, aspects of tamper resistance) rely upon "security 
by obscurity" for effectiveness, which is vulnerable to a lack 
of diversity. Most standardization processes support neither 
the required certification processes nor the short response 
cycles in case of breaches. Industry segments will need to 
provide renewability services and certification infrastructures. 

2) Connected Interoperability 

Connected interoperability builds on the expectation that 
consumers will have online access, and relies upon online 
services, some of them possibly transformative or capable of 
complex negotiation, to solve interoperability problems in a 
transparent way. While different parties may do things in 
different ways, translations or bridges exist between the ways 
different parties perform DRM functions, and that mutually 
trusted parties can perform these translations transparently, as 
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long as devices are connected at least some of the time. 

Pros: Makes it possible for different parties to choose their 
own solutions, and to ensure that security can be renewed, 
while still providing a certain type of interoperability to end- 
users. Shifts the burden of responsibility for interoperability 
from coalitions of manufacturers to on-line service providers. 

Cons: Lacks the straightforward simplicity of full format 
interoperability. Semantic mismatch between different 
systems must be overcome so that cross-boundary content 
flows appear natural. Rights may be restricted to a least 
conunon denominator when crossing boundaries, for technical 
and business reasons. Some classes of products will not meet 
the requirement for online connection. This still requires a 
direct trust relationship between the coordinating parties to 
govern the domains between which transforms should take 
place, or a trusted third party that can negotiate the transform. 

3) Configuration-driven Interoperability 

Configuration-driven interoperability assumes that system 
components ("tools", possibly from different vendors) can be 
downloaded and/or configured in real-time at e.g. the 
consumer's device or software application. This allows 
consumer systems to effectively "acquire" functionality on 
demand in order to accommodate new formats, protocols, and 
so on. Ideally the consumer need not even be aware that the 
dynamic configuration is occurring. This is the main concept 
underlying the MPEG-4 IPMP-X (extensions) approach [17]. 
It emulates the behavior of many software music players that 
can host downloadable compression codecs. 

Pros: Presumes a very late-binding, on-demand model that 
pushes capability to the consumer's system. Depending on 
how the interoperability tools are delivered to the consumer, 
online access may not be required, or at least may be 
minimized once the configuration is installed. 

Cons: Expects that the target platform on which the 
configurable and downloadable tools execute is capable of 
hosting and running an arbitrary number of different 
configurations. This may be troublesome for small consumer 
electronic devices. Multiple formats can be processed with 
multiple hosted tools, but the establishment of trust between 
these components and the host environment still remains - a 
problem that is not yet addressed by MPEG's IPMP work. 

B. Which Approach to Take? 

DRM systems interoperability is a challenging problem and 
there are no easy, universal solutions. While the approaches 
outlined above have individual merits, they are most likely to 
find utility in combination. In order to understand how to 
weigh the trade-offs involved in applying them, we outline a 
set of supporting principles. 

1) Apply Full Format Interoperability Wherever Possible 
Standardization efforts should apply full format 
interoperability as far as they can - things should not be done 
differently just because it is difficult to establish a common 
agreement. Standards should only accommodate alternative 



options when there is a valid technical or business reason to 
do so. Otherwise, the resulting specification may take on so 
much overhead that it becomes too costly or complex for any 
set of parties to achieve an interoperable result. The success of 
the MP3 and MPEG-2 standards is instructive. 

2) Do Not Hide Non-Interoperability, but Minimize It 
When ftill interoperability is not possible, this should not be 

hidden this under layers of abstraction or indirection. They do 
not bring the solution closer, but will make implementations 
more costly and less feasible. In particular, the goal should be 
to put all the non-standard elements in a single, monolithic 
block, and to make these monolithic blocks as small as 
possible, leaving very little to be defined elsewhere. Of all the 
elements left in such a block, DRM interoperability standards 
should carefully consider whether they can be agreed upon 
without compromising security - arguably the only valid 
reason not to agree on a common way to solve a problem. As 
mentioned earlier, the security of some parts of most DRM 
systems depends upon diversity and obscurity. 

3) Employ Transform Services to Bridge Non- 
Interoperability 

Consumer demand and new business opportunities 
frequently introduce the need for interaction with other 
systems built on different agreements and standards. 
Following from the previous principle, non-interoperable 
elements should be defined so that transform tasks (e.g. 
formatting, encoding or license transformations) between 
different systems are as straightforward as possible. This will 
fiirther interoperability in a number of ways: 

• It will reduce the technical issues, thus facilitating design 
and development of transform services 

• It will facilitate the provision of content in different 
systems simultaneously 

• It will facilitate creation of consumer solutions that 
support multiple systems. 

C. Technologies for Full Format Interoperability 
We examine a few pieces of the DRM reference model and 
discuss specific issues around standardization. 

I) Transport Formats, Compression, and Bulk 
Encryption 

Music and especially video presentations are large. For the 
foreseeable future, it will continue to require a noticeable 
amount of network bandwidth, storage space, and computing 
power to move, manipulate, or transform media content. 
Perhaps the greatest advantage from ftill format 
interoperability can be had firom standardizing processes that 
directly manipulate content bits:. This includes transport (file) 
formats, compression (codec) formats, and bulk encryption of 
media bits, for file download, Internet streaming, and 
broadband broadcast. Currently, these technologies are often 
bundled together in proprietary combinations. 
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2) Content Key Distribution 

The security Achilles* heel of most cryptographic systems 
is key management [18], While encrypted content may be 
secured with military-grade algorithms, the content is no more 
secure than are the content encryption keys. What's worse, 
content encryption keys are small and can more easily be 
distributed across the Inteme.t, singly or in bulk, than content 
itself. While DRM-enabled clients are responsible for 
verifying usage rules associated with protected content, any 
security analysis has to consider the possibility that clients 
will be compromised - which is where the art of designing 
key distribution schemes comes into play. The goal is to limit 
the potential damage resulting from a security attack by 
limiting the value exposed to individual clients. One simple 
strategy is to encrypt a conunercial movie with many different 
sets of content keys, so that if an attacker obtains keys to one 
copy of the movie, he cannot reliably redistribute keys to all 
circulating copies of the same movie. In the extreme case, 
content keys can be unique for each copy of a digital work. 

Standardizing key distribution is problematic. Security 
demands that key distribution schemes be obscure (so that 
observers cannot reverse engineer key handling paths), 
diverse (so that successful attacks on one client do not 
compromise the entire infrastructure), and renewable (so that 
compromised systems can recover from attacks). Even the 
means of association between content keys and content files 
may be considered sensitive or renewable information. 

In addition to keeping content keys confidential, DRM 
clients must also worry about keeping identity credentials 
(e.g., private keys) secret. An attacker can obtain content keys 
if it knows how legitimate clients authenticate themselves, or 
prove they are legitimate. It benefits attackers if these 
mechanisms are well known, widespread, and stable. 

One notable key distribution scheme that has been proposed 
for multimedia content protection in home networks is IBM's 
xCP protocol [19]. xCP uses a symmetric key distribution 
scheme ("broadcast encryption" [20]) originally developed for 
multicast applications. Each content key is locked inside a 
large Media Key Block, which is made available to devices on 
the network. Each device protects a set of secrets, which it can 
use to unlock Media Key Blocks and obtain content keys. If a 
device leaves a network, perhaps by being "revoked", then the 
revoked device's keys will no longer unlock newly generated 
Media Key Blocks. Standardized multicast key distribution 
schemes would be beneficial for distribution of content keys 
on fixed media, such as CD's or DVD's, since for this 
distribution mechanism there is no possibility of negotiation 
between the consuming client and the key provider. 

3) Provisioning and Security Services 

Every consuming device or application that provides or 
consumes cryptographic services must be provisioned or 
initialized with its individual set of secrets, trust anchors, and 
credentials. Many consuming devices will need to use other 
security services, in order to receive security upgrades, to 
refresh keys and certificates, to contact secure time servers. 



and to report suspected security attacks. 

There are two related difficulties with standardizing such 
security services. The first difficulty relates to client privacy 
issues. The second difficulty stems from the requirement for 
clients to authenticate and prove their integrity to remote 
services. Platform integrity is further related to tamper 
resistance, which in practice is based on proprietary 
techniques. New computing platform security and integrity 
standards [13] may help. 

4) Trust Management 

No multi-vendor multi-component system can operate 
without a means for establishing and verifying trust among the 
components and the entities served by the components. The 
best known standardized trust management system is the 
hierarchical PKI model first put forward in the X.509 standard 
[21]. The basic X.509 system uses hierarchical certifications 
and anchors trust in a root certification authority. Public-key 
cryptography provides the technical means of verifying the 
integrity of certificates. 

Trust management decisions must be made on client 
devices, and may be required more often than content access 
control decisions. Hence, the complexity of trust management 
operations is of concern. Public key cryptography operations, 
especially producing digital signatures, are computationally 
expensive. Trust models for backend services can be more 
elaborate, although performance is still an issue there. 

Hierarchical trust models with top-level "roots of trust" are 
convenient for closed-system deployments, but are 
problematic for dynamic, global deployments. First, a root of 
trust takes at least delegated responsibility as a certification 
authority for his descendent entities, but it carmot be expected 
that a single authority will be competent or willing to take 
such responsibility universally for all credential-issuing 
entities. Some entities should be trusted independently of 
others. This makes sense also when trust relationships are 
dynamic. Second, a system that relies on a root of trust 
becomes a slave to its own success. The number of parties 
relying on the root of trust makes it very difficult for the root 
to modify its policies and procedures. This seriously inhibits 
the system from growing and innovating. In the most general 
case, each stakeholder in a transaction or activity should act as 
his own ultimate root of trust. He may delegate trust to well- 
known authorities, but the system should support independent 
selection of trust authorities and trust anchors [12]. 

While trust itself can not be standardized, standardization of 
trust management for media DRM should be possible, but the 
first steps must be identification of a dictionary or vocabulary. 
It must be decided who needs to be trusted, to perform what 
activity, under what conditions. This is probably more 
important to standardize than the exact language for 
computing decisions based upon trust policy and evidence. 

5) Usage Rule Expression 

Producers and consumers of content need to share a 
common license language for expressing the usage rules 
attached to content. As with trust management, the 
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standardization of vocabulary and identifiers is probably more 
crucial than the choice of a specific language. Every DRM 
system in deployment has a means of expressing usage rules. 
Probably the simplest is the 4C Entity's Copy Control 
Information (CCI [22],[23],[24]), used in the 5C 
DTCP/Firewire access control standard [25] and the 
DVD/CSS access control system [26]. The Copy Control 
Information for a digital work consists of two bits, indicating 
whether the work can be copied one generation, copied never, 
no more, or freely. A copy of ''copy once" content is per force 
"copy no more" content. "Copy never" content differs from 
"copy no more" content, in that "copy never" content should 
only appear in its original form, never in a copied form. 

At the other end of the spectrum is the MPEG-21 REL [8], 
which defines a vocabulary of media-related concepts, and 
inherits by extension a larger vocabulary through the MPEG- 
21 Rights Data Dictionary. REL is purely declarative, 
resembling a logic programming language in that it supports 
"for all" quantified variables, assertions of fact, and recursive 
computation. REL supports delegation and chaining of 
licenses (through the "issue" right), although the way REL 
chaining interacts with the time line differs from other chained 
assertion languages like SPKI [27] or X.509. These features 
give REL much of its expressive power and also much of its 
complexity. REL's syntax is expressed in XML, which makes 
typical licenses much larger than the two bits required for AC 
Copy Control Information. 

There are many other rights expression formats in use. Paul 
Kocher advocates a system that uses a virtual machine 
bytecode to express licensing, security, and trust conditions, 
written against a standard API of host-supplied services [28]. 
Similar concepts were also explored by the OPIMA standards 
project [29]. Kocher argues that the delivery of bytecode 
means that security implementations can be renewed with 
each new piece of content, but other techniques must still be 
used to renew the implementation of the virtual machine, and 
to prevent reverse engineering of the virtual machine. 

IV. NEMO - AN Approach to Connected 

INTEROPERABILFTY 

Some interoperability problems, especially those involving 
heterogeneous DRM systems, can be addressed by employing 
on-line negotiations. This is becoming more feasible in 
today's climate of ubiquitous always-on or frequently-on 
network access. NEMO (Networked Environment for Media 
Orchestration [30]) is an experimental framework being 
developed at InterTrust for the discovery, access, composition, 
and orchestration of media-related on-line services. 

A. An Introduction to NEMO 

NEMO allows service access across multiple network tiers 
- wide area networks, local area networks, home networks 
{e.g., over UPnP [31] or Rendezvous [32]), and personal area 
networks (e.g., over Bluetooth [33]). NEMO supports multiple 
local and remote interface bindings (e.g. WS-I [34], Java 
RMI, DCOM, C, .Net, etc.) allowing integration with 



applications. NEMO allows the use of multiple discovery 
protocols (UDDI [35], JINI [36], UPnP, Rendezvous) for 
finding NEMO services. NEMO supports (and encourages) 
the active composition and orchestration of services to 
perform complex tasks on-line. The idea is that orchestration 
and composition will allow service configurations to adapt 
and optimize to changing needs, such as when a personal area 
network moves into range of new home network devices. 

An instance of the NEMO framework consists of a logically 
cormected set of nodes that interact in a peer-to-peer fashion. 
NEMO nodes interact by making service invocation requests 
and receiving responses. The format and pay load of the 
request and response messages is defined in XML. The 
NEMO framework supports the construction of diverse 
communication patterns ranging from direct interaction with a 
single service provider to a complex aggregation of a 
choreographed set of services from multiple service providers. 
The framework supports the basic mechanisms for using 
existing service choreography standards and allows service 
providers to use their own conventions. 

A service interface may have one or more service bindings. 
A NEMO node may invoke the interface of another node as 
long as that node's interface binding is described and the 
requesting node can support the conventions and protocols 
associated with the binding. E.g., if a node supports a web 
service interface, a requesting node may be required to 
support SOAP, HTTP, WS-Security, etc. Any service 
interface may be controlled in a standardized fashion directly 
providing aspects of rights management. All interactions 
between NEMO nodes can be viewed as governed operations. 

The Workflow Collator (WFC) helps fulfill most non-trivial 
NEMO service requests by coordinating the flow of events of 
a request, managing any associated data including transient 
and intermediate results, and enforcing the rules associated 
with fulfillment. Other examples of this type of functionality 
can be seen in the form of transaction coordinators ranging 
from simple transaction monitors in relational databases to 
more generalized monitors as seen in Microsoft MTS/COM+. 
The Workflow Collator is a programmable mechanism 
through which NEMO nodes orchestrate the processing and 
fulfillment of service invocations. 

We use the concept of profiles as an organizing principle in 
NEMO. A profile is the set of thematically related data types 
and interfaces defined in WSDL for the NEMO framework. 
Currently we have two profile categories: "Core", which 
includes the foundational set of data types and service 
messages necessary to support fundamental NEMO 
framework interaction patterns and functionality, and "DRM" 
which describes the Digital Rights Management services that 
can be realized with NEMO. 

Some services defined in the NEMO Core profile include: 

• Authorization - services related to authorization of a 
participant (such as node) to use a resource (service). 

• Peer Discovery - services related to the discovery of 
NEMO nodes. 

• Notification - services related to the delivery of targeted 
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messages to a given set of nodes. 

• Service Discovery - services related to the discovery of 
services provided by some set of service providing nodes. 

Some basic services defined in the NEMO DRM profile 
include: 

• Provisioning - services for obtaining the necessary 
credentials, policy, and other objects necessary for a 
consumer electronics device, software application, etc to 
participate within a specific context that uses DRM. 

• Licensing - services for obtaining DRM licenses. 

• Membership - services for obtaining objects that establish 
membership within some designated domain. 

We have not yet tried to define a formal categorization of 
NEMO peer roles based on service type groupings. However, 
based on existing functionality and observed patterns we have 
defined a preliminary set of roles that may be formalized over 
time. These include: 

Client - this is the simplest role where no services are 
exposed and the peer simply uses services of other peers. 

Authorizer - this role denotes a peer acting as a Policy 
Decision Point (PDP) determining if the requesting principal 
has access to a specified resource with a given set of pre- 
conditions and post-conditions (consequences, obligations) 
[37]. 

Gateway - in certain situations a peer may not be able to 
directly discover or interact with other service providers, for 
reasons including: transport protocol incompatibility, inability 
to negotiate a trusted context, or lack of the processing 
capability to create and process the necessary messages 
associated with a given service. The Gateway role denotes a 
peer acting as a bridge to another peer in order to allow 
interaction with a service provider. From the perspective of 
identity and establishing an authorized and trusted context for 
operation, the requesting peer may actually delegate to the 
Gateway peer its identity and allow that peer to negotiate and 
make decisions on its behalf Alternatively, the Gateway peer 
may act as a simple relay point forwarding or routing requests 
and responses. 

Orchestrator - in situations where interaction with a set of 
service providers involves some type of non-trivial 
coordination of services possibly including transactions, 
distributed state management, etc, it may be beyond a peer's 
capability to participate in such a scenario. The Orchestrator 
role is a specialization of the Gateway role. A peer requests an 
Orchestrator peer to act on its behalf, intervening with one or 
more services. The orchestrating peer may use certain 
additional NEMO components such as an appropriately 
configured Workflow Collator in order to satisfy the 
orchestration requirements. 

B. Consumer Media Applications 

Since our ultimate goal is to enable the oft-repeated "instant 
gratification of request for any media, in any format, from any 
source, to any place, at anytime, on any device complying 
with any agreeable set of usage rules," we developed an 



informal model that helps us demonstrate how we use NEMO 
to achieve this goal. This model helped us in the separation of 
concerns process in system architecture discovery. The model 
is roughly aligned with the Basic DRM Reference Model 
outlined previously, but is more specialized for our networked 
application. The model spans heterogeneous network tiers, 
and illustrates some realistic interoperability problems. We 
explain the highest level of the model, and then we show how 
NEMO allows low level services from different tiers in the 
model to be assembled into richer end-to-end media services 

I) A Media Distribution Model 
In this model there are four tiers of service components: 

1) Content Authoring, Assembly, and Packaging services, 

2) Web-based Content Aggregation and Distribution 
services, 

3) Home Gateway services, and 

4) Consumer Electronics (CE) devices. 

Each of these four tiers clearly has significantly different 
requirements for security, rights management, service 
discovery, service orchestration, user interface complexity, 
and other service attributes. The first two tiers fit very roughly 
into the models that we see for "traditional" web services, 
while the last two tiers fit more into what we might call a 
personal logical network model, with certain services of the 
home gateway being at the nexus between the two types of 
models. However, services of CE devices could occasionally 
appear in any of the tiers. Thus, we have the dilenruna where 
we want to specialize parts of the framework for efficiency of 
implementation, while being general enough to encompass an 
end-to-end solution. 

For relatively static and centralized web services, a UDDI 
directory and discovery approach may work well, but for a 
more dynamic transient merging of personal networks, 
discovery models such as found in UPnP and Rendezvous are 
more appropriate. Thus, we need to be able to include multiple 
discovery standards in our framework. 

When rights management is used for media distribution 
through wholesale, aggregator, and retail distribution subtiers, 
there can be many different types of complex rights and 
obligations that need to be expressed and tracked. This 
requires a highly expressive and complex rights language, 
sophisticated content governance and clearing services, and a 
global trust model. However, rights management and content 
governance for the home gateway and CE device tier 
generally requires a different trust model and needs to 
emphasize fair use rights that are straightforward from the 
consumer's point of view. Peer devices in a personal logical 
network want to interact using the simple trust model of that 
network, and they need to interact with peers across a wide 
area network using a global trust model perhaps through 
proxy gateway services. 

At the consumer end, complexity arises from automated 
management of content availability across devices, some of 
which are mobile and intermittently intersect multiple 
networks. Thus, our approach to rights management, while 
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enabling end-to-end distribution, is heterogeneous, supporting 
a variety of rights management services, including services 
that interpret distribution rights expressions and translate 
them, in context, to individual consumer fair use rights in a 
transaction that is orchestrated with a sales transaction or 
another event where a subscription right is exercised. 

2) NEMO Solutions 

We are currently using NEMO to link various consumer 
devices to a number of different services in the multi-tiered 
environment described above. We have successfully 
demonstrated interoperability in one interconnected system 
using cell phones, game platforms, PDAs, PCs, web-based 
content services, discovery services, notification services, and 
update services. We support multiple media formats (e.g. 
MP4, Windows Media, and others), multiple discovery 
protocols (over Bluetooth and through registries such as 
UDDl, LDAP, and Microsoft Active Directory), and IP-based 
notification and wireless SMS notification on the same device. 
We use the orchestration feature to help the consumer 
overcome interoperability barriers. When there is a query for 
content, orchestration coordinates the required services in 
order to fulfill the request, including, discovery, search, 
matching, update, rights exchange, and notification services. 

We are attempting to converge on a state where a consumer 
can use most any device, make a wish for content, and be 
instantly fulfilled with the content and the rights and rendering 
capabilities (within obvious limits of the hardware) to both 
use and share the content. The orchestration capability allows 
the consumer to view all home and internet-based content 
caches from any device at any point in a dynamic multi-tiered 
network. We are extending this capability to more advanced 
services that promote sharing of streams and play lists, 
making impromptu broadcasts and narrowcasts easy to 
discover and connect to, using many different devices, while 
ensuring rights are respected. 

3) Connected Interoperability 

Beyond the consumer-centric side, we are looking at ways 
to provide an end-to-end interoperable media distribution 
system that does not rely on a single set of standards for media 
format, rights management, and fulfillment protocols. Value 
chains that include content originators, distributors, retailers, 
service providers, device manufacturers, and consumers, 
exhibit a number of localized needs in each segment. This is 
especially true in the case of rights management, where 
content originators need to express rights of use that may 
apply differently in various contexts to different downstream 
value chain elements. A consumer gateway has a much more 
narrow set of concerns, and an end user device has a yet 
simpler set of concerns, namely just playing the content. 

With a sufficiently automated system of dynamically self- 
configuring distribution services, content originators can 
produce and package content, express rights, and confidently 
rely on value added by other service providers to instantly 
provide the content to all interested consumers, no matter 



where they are or what kind of device they are using. We use 
NEMO to fulfill this goal and provide means for multiple 
service providers to innovate and introduce new services that 
benefit both consumers and service providers without having 
to wait for or depend on a monolithic set of standards. 

This approach allows digital rights management to be 
decomposed into components with a more natural separation 
of concerns that focus on policy management of service 
interfaces rather than on copy protection. This has the 
potential to change the tension between consumers and 
content providers in the digital content domain as the NEMO 
enriched infirastructure provides consumers with better 
information, more useful services and instant gratification. 
Policy management can limit the extent to which pirates can 
leverage those legitimate services. NEMO allows the network 
effect to encourage the evolution of a very rich set of 
legitimate services providing better value than pirates can 
provide. -H 

V. Conclusions 

We have argued that interoperability is very important to 
the success of DRM. We have explained the concepts behind 
digital rights management, and provided a basic reference 
model that embodies patterns representative of current 
architectures, and which can serve as a basis for coordination 
of interoperability solutions in next generation DRM systems. 
We have enumerated the pros and cons of three separate 
approaches to DRM interoperability, and discussed issues 
related to standardization of specific DRM-related 
technologies. We have presented an experimental system that 
supports interoperability of heterogeneous DRM systems via 
on-line services and service orchestration. 

Looking forward, DRM systems must continue to evolve in 
order to achieve interoperable, secure, media-related 
ecommerce in a world of heterogeneous consimier devices, 
media formats, conmiunication protocols and security 
mechanisms. Today significant barriers exist to the goal of an 
interoperable and secure world of media related services. 
Standardization can solve some interoperability problems, but 
standards are not always universally applied. Where 
heterogeneous systems exist, dynamic late-bound network 
services can supply required functionality, including bridging 
services. But, in the end, DRM is about protection. A DRM 
system will not interoperate if it does not want to. 

Acknowledgment 

The authors gratefully acknowledge valuable discussions 
and input from David Maher, William Bradley, Talal 
Shamoon, and Albhy Galuten. 

References 

[ 1 ] G. A, Lyon, "A Quick-Reference List of Organizations and Standards for 
Digital Rights Management", N 1ST Special Publication 500-241, 
October 2002. 

[2] J. Borland, "Apple Unveils Music Store", in CNET Newsxom, April 28, 
2003. http://news.com.com/2100-1027 3-998590.html?tag=m 



16 



[3] J. Graham, "Downloaders dance to Apple's iTunes", in USA Today, 
December 15, 2003. http://www.usatoday.com/tech/news/2003-12-14- 
apple2_x.htm 

[4] DRM Watch Staff, "More Paid Download Music Services to Launch in 

Early 2004", DRM Watch, December 1 1, 2003. 

http://www.drmwatch.com/ocr/article.php/3287471 
[5] Esprit WP4, The IMPRMATVR Business Model Version 2 J 

http://www.imprimatur.net/IMP FTP/BMv2.pdf 
[6] N. Friesen, Towards a Digital Rights Expression Language Standard for 

Learning Technology, 
[7] O. Sibert, et. a!.. Securing the Content and Not the Wire, Technical 

Report, InterTnist Technologies, Inc. 1 996. 
[8] ISO/IEC JTC 1 SC29 WG 1 1 {M?EG) JSO/IEC 21000-4 Rights 

Expression Language, to be published by ISO in 2004 
[9] R. lanella. Open Digital Rights Language Specification v 1.0, see 

www. w3 ,org/TR/odrl/ 
[10] Content Reference Forum, Content Reference Forum Introduction. CRF- 

004, 2003. 

http://www.crforum.org/crfreppub/CRF004 002 or forum overview.pd 
f 

[II] J. Feigenbaum, et al.. Privacy Engineering for Digital Rights 
Management Systems. 

http://citeseer.ni.nec.com/cache/papers/cs/25597/http:zSzzSzwww.star- 
lab.comzSzsanderzSzpublicationszSzspdrmOl.pdf/feigenbaumOl privacy 
.pdf 

[12] S. Weeks, et. al., Understanding Trust Management Systems. InterTrust 
STAR Lab, Technical Report STAR-TR-01-02, March, 2001. 

[13] Trusted Computing Group, TCG Main Specification, Version 1.1a, 
September 200 1 . hltps://www.trustedcomputinggroup.org/home 

[14] B. Home, et. al.. "Dynamic self-checking techniques for improved 

tamper-resistance", in Proceedings of Workshop on Security and Privacy 
in Digital Rights Management 2001, Association of Computing 
Machinery, http://citeseer.ni.nec.com/home01dynamic.html 

[15] W. Shapiro, et. al.. How to Manage Persistent State in DRM Systems, 
InterTrust STAR Lab, Technical Report STAR-TR-01-06, August, 2001. 

[ 1 6] Chr. Barlas (ed.). Digital Rights Management Final Report, 
http://euroDa.eu.int/comm/enterprise/ict/Dolicv/doc/drm.pdf 

[17] ISO/IEC JTCl SC29 WGl I (MPEG). ISO/IEC- 1 4496- 13 Final Draft 
International Standard, (MPEG-4 IPMP Extensions). 

[18] B. Schneier, Applied Cryptography Second Edition, John Wiley & Sons, 
Inc., 1996. 

[19] F. Prestoni, xCP Cluster Protocol ~ IBM Response to DVB-CPT Call for 
Proposals for Content Protection & Copy Management, International 
Business Machines Corporation, October, 200 1 , 
http://www.almaden.ibm.com/software/ds/ContentAssurance/prez/xCP_ 
DVB.ppt 

[20] A. Fiat, and M. Naor, "Broadcast Encryption", in Advances in 

Cryptology — CRYPTO '93. Springer- Verlag, Berlin, 1994, pp. 480- 
491. 16 

[21] International Telecommimications Union. ITU-T recommendation 

X.509 (08/97) - information technology - open systems interconnection 
- the directory: Authentication framework, August 1997. 

[22] M. Ripley, C. Traw, S. Brendan, S. Balogh, and M. Reed, "Content 

Protection in the Digital Home", in Intel Technology Journal, November 
2002. http://developer.intel.com/technology/itj/2002/volume06issue04/ 

[23] 4C Entity LLC, Content Protection System Architecture: A 
Comprehensive Framework for Content Protection, Revision 0.81, 
February 2000, http://www.4centitv.com/data/tech/cpsa/cpsa08 1 .pdf . 

[24] J. A. Bloom, I. J. Cox, T. Kalker, J.-P. Linnartz, M. L. Miller, and B. 
Traw. Copy protection for DVD video. Proceedings of the IEEE, 87(7): 
1267 — 1276, 1999. http://citeseer.ni.nec.com/bloom99copv.html . 

[25] 5C Digital Transmission Content Protection White Paper. Revision I.O, 
July 1998, htt p : //www . dtcp . com/data/ wp spec . p df 

[26] DVD Copy Control Association, http://www.dvdcca.org 

[27] C.M.,Ellison, B. Frantz, B. Lampson, R.L. Rivest, B.M. Thomas, and T. 
Ylonen, "SPKI certificate theory". IETF RFC 2693, September 1999. 

[28] P. Kocher, J, Jaffe. B. Jun, N. Lawson, Self Protecting Digital Content, 
Cryptography Research, Inc., 2003. 

http://www.crvptographv.com/resources/whitepapers/SelfProtectingCont 
ent.pdf 

[29] lEC IT A, OPIMA Specification, Version 1. 1, June, 2000, 
http://leonardo.telecomitalialab.com/opima/ 



[30] W, Bradley D. Maher, "The NEMO P2P Service Orchestration 

Framework", In Proceedings of the 37th Annual Hawaii International 

Conference on System Sciences (HICSS-37), January 2004. 
[31] UPnP Forum, Basic Device V \ .0 Pwfih, MediaServer V 1 .0 and 

MediaRenderer V 1.0 Profile, Internet Gateway Device (IGD) V LO 

Profile, http://www.upnp.org/ 
[32] Apple/Darwin Group, Rendezvous, 

http://developer.apple.com/darwin/proiects/rendezvous/ 
[33] Bluetooth.org, Bluetooth Core Specification. I.OB, January 2003 , 

https://www.bluetooth.org/docman2/ViewProperties.php?group_id=53& 

document_content_id=3 30 
[34] S. Werden, C. Evans, M. Goodner, WS-I Usage Scenarios, Web Services 

Interoperability Organization (WS-I), http://www.ws-i.org/ 
[35] T. Bellwood, (ed.). Universal Description, Discovery and Integration 

(UDDI) V2, OASIS Standard, 19 July 2002. 

http://www.uddi.org/specification.html 
[36] B. Joy, and J. Waldo, Jini Network Technology, Sun Microsystems, 

March 1999, http://wwws.sun.com/software/jini/ 
[37] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based 

Admission Control," RFC2753, http://www . ietf.org/rfc/rfc275 3 



Rob Koenen (M'97-SM'OO) holds an MS degree in electrical engineering 
from the Technical University of Delft, the Netherlands, '89. 

He works with InterTrust Technologies in Santa Clara, CA, US. Before 
joining InterTrust, he was a research director at KPN Research in The 
Netheriands for 10 years. His numerous projects with KPN included: image 
coding research, audio/visual conununication for people with special needs, 
interactive broadband multimedia for residential users, mobile multimedia, the 
strategic development of new multimedia services, audio/visual quality 
assessment and multimedia standardization. 

Mr. Koenen is Associate Editor of IEEE Transactions on Circuits and 
Systems for Video Technology, chairman of MPEG*s Requirements Group, 
and founder and current President of the MPEG Industry Forum, MPEGIF. 

Jack Lacy received his MS degrees fi-om the University of Wisconsin in 
Physics, 1979 and from New York University in Computer Science, 1987. 

Prior to joining InterTrust, he spent 18 years as a researcher at Bell 
Laboratories, Bell Labs and AT&T Labs working in a variety of areas related 
to networking and computer security, including systems for sending voice 
over IP networks, cryptography, and secure systems architecture. He is a co- 
inventor of Cryptolib, a widely distributed cryptographic library, and 
Policymaker, an AT&T developed approach to specifying and interpreting 
security policies, credentials, and relationships. Mr. Lacy has also been active 
in intellectual property protection and management through his involvement in 
standards setting organizations, such as MPEG, OPIMA and SDMI. He 
chaired the SDMI Portable Device Working Group from March - September 
1999. 

At InterTmst he is responsible for media standards activities, technical 
requirements for advanced development projects, development of system 
architectures and prototypes, particularly around Media technologies, and 
determination of InterTrust's interfaces to open technology standards. 

Michael MacKay is Executive Vice President for Standards, Policy and 
Specifications at InterTrust Technologies in Santa Clara, California. He has 
held several executive engineering positions with InterTrust since 1999. As 
Senior VP, Engineering he led research and development of the 
Rights|System, DRM Platform. Prior to joining InterTmst, Mr. MacKay was 
VP, Corporate Architecture for Novell, Inc. where he led design projects and 
standards development in support of the NetWare 5 platform. Prior to joining 
Novell, Mr. MacKay worked for Taligent where he was responsible for class 
framework architecture. Mr. MacKay also spent 15 years with Xerox 
Corporation where he worked on a variety of technologies including 
distributed printing services, stmctured document-processing systems, 
printing languages, and a variety of printing systems and services products. 

He has been a contributor in multiple standards bodies including IETF, 
DMTF, and ISO, and is a former member of the board of directors for the 
Object Management Group. Mr. MacKay is a member of the ACM. 

Steve Mitchell (M'84) (b. Toronto, 1961) BS electrical engineering 1984 
(Georgia Tech), MS applied mathematics 1986 (Georgia Tech), MS computer 
science 1989 (Cornell U.) has studied theory of computation, signal 
processing, and bioacoustics. 



Since 1999 he has worked as a member of the technical staff of InterTrust 
Technologies in Santa Clara* California, on projects relating to multimedia 
content protection, enterprise policy administration and analysis, and digital 
multimedia watermarking. 

Mr, Mitchell is a member of several professional societies, including the 
IEEE. 



